home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Internet Tools 1995 April / Internet Tools.iso / infoserv / www / cern / doc / www-talk.archive.Z / www-talk.archive / text0432.txt < prev    next >
Encoding:
Text File  |  1992-11-30  |  6.9 KB  |  209 lines
  1.  
  2. OK, now you're asking for it. I've been mulling this
  3. stuff over in my head for a couple weeks, and I've got some
  4. pretty good ideas as to how it all fits together.
  5.  
  6. My model of global hypermedia includes the following terms:
  7.  
  8. Entity -- SGML and MIME use this term. WAIS calls it a document.
  9.     Gopher calls it an item or a textfile or something.
  10.     WWW used to call it a document, and now calls it
  11.     a resource.
  12.  
  13.     The meaning is the same in all of them: a unit
  14.     of retrieval [from the URL document].
  15.  
  16. Content-Type -- MIME coined this term. SGML calls it a NOTATION.
  17.         WAIS used to call it :type, but they'll call
  18.         it :content-type if they follow up on what they
  19.         told me. Most gopher types fall under this scheme
  20.         (telnet, cso, and other types that don't use gopher
  21.         protocol don't fit)
  22.  
  23. Reference -- This is the WWW anchor, the Gopher Menu item, the WAIS
  24.     :document-id structure, The MIME message/external-body. It is
  25.     enough information to 1) decide whether to retrieve the entity,
  26.     2) perform the retrieval transaction, and 3) process the entity
  27.     once you've got it.
  28.  
  29. >Really, though, the gopher reference is (in gopherspeak)
  30. >
  31. >Name=An arbitrary, but meaningful name
  32. >Host=gopher.micro.umn.edu
  33. >Port=70
  34. >Type=0
  35. >Path=Some Stuff
  36.  
  37. NOTE: Some Stuff is terminated by a newline, and may not contain tabs.
  38.  
  39. >And the "href=" is just a way to squash it down to a single string.
  40. >It could just as well be a set of attributes and not a single one.
  41. >E.g.
  42. >
  43. ><a gopherhost="gopher.micro.umn.edu" 
  44. >   gopherport="70" 
  45. >   gopherpath="/Some Stuff" 
  46. >   gophertype="0">
  47. >An arbitrary, but meaningful, name</a>
  48.  
  49. NOTE: for type 7 items, you need gophersearch="terms" too.
  50.  
  51. >expresses the meaning of what's going on in a way that's far closer to
  52. >how SGML might do it as far as I have been able to make out...Dan is
  53. >that actually legal SGML?
  54.  
  55. Sure, that's legal. I suggested that URLs be expressed in SGML a long
  56. time ago. Tim said it was overkill, and I'm starting to agree.
  57.  
  58. Let's take a closer look at references:
  59.  
  60. 1) What features allow users and clients to decide to retrieve an entity:
  61.  
  62. WWW    context and content of the anchor (Is it relevant?)
  63.  
  64. MIME    content-id (do I have this entity cached already?)
  65.     content-description (relevant?)
  66.     content-type (can I process it once I've got it?)
  67.     SIZE (is it too big to bother?)
  68.  
  69. WAIS    :score (relavent to my query?)
  70.     :headline (relevant?)
  71.     :doc-id (in cache?)
  72.      original/distributor-server,database,local-id particularly useful
  73.     :number-of-lines, :number-of-bytes (too big?)
  74.     :type, :content-type (can I process it?)
  75.     :date (how old is it?)
  76.  
  77. Gopher    name (is it interesting?)
  78.     type (can I process it?)
  79.  
  80. 2) What features allow the client to make the transfer?
  81.  
  82. WWW    URL -- protocol, host, port, path, type, size, search terms
  83.     handles local files, HTTP, gopher, WAIS connections.
  84.     includes search terms for fulltext indexes.
  85.     scheme mechanism allows gateways to new protocols
  86.  
  87. MIME    access-type, etc.: handles ftp, anon-ftp, local-file
  88.     Ghost body allows arbitrary extra data.
  89.  
  90. Gopher    host, port, path, search words
  91.  
  92. WAIS    source (host, port, database), doc-id, search terms,
  93.     relavent documents (these are the novel feature. Quite handy)
  94.  
  95. 3) What features allow the client to process the entity?
  96. (Keep in mind that these are features of the reference -- this
  97. is information we have _before_ we transfer the entity).
  98.  
  99. WWW    processing is tied to the protocol. Content-Type
  100.     of local files is inferred from file extensions.
  101.  
  102.     Entities from HTTP connections are assumed to
  103.     be text/x-html.
  104.  
  105.     Gopher entites are typed: 0=text/plain, 1=application/x-gopher,
  106.     w=text/x-html.
  107.  
  108.     WAIS entites are typed: TEXT=text/plain, WSRC=application/x-wais.
  109.  
  110. MIME    content-type mechanism is quite expressive. Any content-type
  111.     can be encapsulated in a message/rfc822 entity. Multiple
  112.     entities can be encapsulated in a multipart/mixed entity.
  113.  
  114. Gopher    gopher type tells you what to do with the data.
  115.     text/plain, application/x-gopher are universally supported.
  116.     other types are supported by pilot projects.
  117.  
  118. WAIS    :type tells what to do. text/plain and application/x-wsrc are
  119.     supported. Other types are supported by pilot projects.
  120.  
  121.  
  122. Now let's see how we should change the WWW reference mechanism.
  123.  
  124. Here's what we've got currently:
  125.  
  126. <!ELEMENT A    - -  (#PCDATA)>
  127. <!ATTLIST A
  128.     NAME ID #IMPLIED
  129.     HREF CDATA #IMPLIED
  130.     TYPE CDATA #IMPLIED
  131.     >
  132.  
  133. What's the TYPE used for? It's not a data type. There's some
  134. code in LineMode to handle it, but I'm not sure what it does.
  135.  
  136. The NAME identifies the anchor as the target of some other anchor.
  137. We should have NAME (or ID) attributes on pretty much all elements,
  138. for example:
  139.  
  140. <DL>
  141. <DT ID=term>term<DD>definition
  142. </DL>
  143.  
  144. The HREF attribute is enough information to retrieve and Entity.
  145. Good. But it's got thie #anchor stuck on the end. That should
  146. be a separate attribute. It should be an IDREF, so that we
  147. can validate that it references an existing ID with an SGML
  148. parser.
  149.  
  150. "But," you say, "what if it references an ID outside the current document?"
  151.  
  152. I suggest we treat a group of nodes that reference each other not
  153. as separate documents, but as entities of one big document. That
  154. way, an author can validate the internal links in his/her web.
  155.  
  156. I suggest two new elements: XREF, for intra-document links (i.e.
  157. links within the local web), and SEE for inter-document links
  158. (i.e. links that go outside the local web).
  159.  
  160. <!ELEMENT XREF - - (#PCDATA)
  161.  -- This element is for links within an HTML document. (a document
  162.     is a collection of entities, or a web of nodes).
  163.  -->
  164. <!ATTLIST XREF
  165.     CONTEXT CDATA #IMPLIED -- entity containing the XREF is implied --
  166.     -- SGML purists would make this attribute an ENTITY reference,
  167.        and put the URL in the SYSTEM identifier in the prologue.
  168.        For expediency, we put the URL right in the attribute.
  169.     --
  170.     ORIGIN CDATA #IMPLIED
  171.     -- another URL, used as an identifier, rather than a locator.
  172.        Ala the WAIS original-server,database,local-id triple.
  173.     --
  174.     REF IDREF #REQUIRED  -- ID of referent element --
  175.     >
  176.  
  177. <!ELEMENT SEE - - (#PCDATA)
  178.  -- This element is for links from an HTML document to any entity
  179.     in the global web. The location and content-type of the entity
  180.     are sufficient to resolve the reference.
  181.  
  182.     The other attributes could be specified in the text of the
  183.     SEE content, but by making them attributes, the client software
  184.     can process them, for example, to display a table of references
  185.     sorted by date.
  186.  -->
  187. <!ATTLIST SEE
  188.     LOCATION CDATA #REQUIRED -- URL of referent entity --
  189.     CONTENT-TYPE CDATA #REQUIRED -- MIME Content-Type for the entity --
  190.     CHUNK CDATA #IMPLIED
  191.     -- This is the analogue of the #anchor mechanism.
  192.        If CONTEXT is an SGML entity, this would be an ID,
  193.        though it won't be validated.
  194.        However, if CONTEXT is a text file, this could be a line number.
  195.        The meaning is defined by the content-type.
  196.     --
  197.     ORIGIN CDATA #IMPLIED
  198.     FROM CDATA #IMPLIED -- email address or name of author/provider --
  199.     DATE NUMBER #IMPLIED -- in ISO format: YYYYMMDDHHMMSSZ --
  200.     BYTES NUMBER #IMPLIED -- useful in many cases --
  201.     MD5 CDATA #IMPLIED -- data signature --
  202.     >
  203.  
  204. What do you think?
  205.  
  206. Dan
  207.  
  208.  
  209.